tools/xl/bash-completion: also complete 'xen'

We have the `xen` alias for xl in Debian, since in the past it was a
command that could execute either xl or xm.

Now, it always does xl, so, complete the same stuff for it as we have
for xl.

Signed-off-by: Hans van Kranenburg <hans@knorrie.org>
[git-debrebase split: mixed commit: upstream part]

pygrub: Specify -rpath LIBEXEC_LIB when building fsimage.so

If LIBEXEC_LIB is not on the default linker search path, the python
fsimage.so module fails to find libfsimage.so.

Add the relevant directory to the rpath explicitly.

(This situation occurs in the Debian package, where
--with-libexec-libdir is used to put each Xen version's libraries and
utilities in their own directory, to allow them to be coinstalled.)

Signed-off-by: Ian Jackson <ian.jackson@citrix.com>

pygrub: Set sys.path

We install libfsimage in a non-standard path for Reasons.
(See debian/rules.)

This patch was originally part of `tools-pygrub-prefix.diff'
(eg commit 51657319be54) and included changes to the Makefile to
change the installation arrangements (we do that part in the rules now
since that is a lot less prone to conflicts when we update) and to
shared library rpath (which is now done in a separate patch).

(Commit message rewritten by Ian Jackson.)

Signed-off-by: Ian Jackson <ian.jackson@citrix.com>
squash! pygrub: Set sys.path and rpath

hotplug-common: Do not adjust LD_LIBRARY_PATH

This is in the upstream script because on non-Debian systems, the
default install locations in /usr/local/lib might not be on the linker
path, and as a result the hotplug scripts would break.

A reason we might need it in Debian is our multiple version
coinstallation scheme.  However, the hotplug scripts all call the
utilities via the wrappers, and the binaries are configured to load
from the right place anyway.

This setting is an annoyance because it requires libdir, which is an
arch-specific path but comes from a file we want to put in
xen-utils-common, an arch:all package.

So drop this setting.

Signed-off-by: Ian Jackson <ian.jackson@citrix.com>

sysconfig.xencommons.in: Strip and debianize

Strip all options that are for stuff we don't ship, which is 1)
xenstored as stubdom and 2) xenbackendd, which seems to be dead code
anyway. [1]

It seems useful to give the user the option to revert to xenstored
instead of the default oxenstored if they really want.

[1] https://lists.xen.org/archives/html/xen-devel/2015-07/msg04427.html

Signed-off-by: Hans van Kranenburg <hans@knorrie.org>
Acked-by: Ian Jackson <ijackson@chiark.greenend.org.uk>

vif-common: disable handle_iptable

Also see Debian bug #894013. The current attempt at providing
anti-spoofing rules results in a situation that does not have any
effect. Also note that forwarding bridged traffic to iptables is not
enabled by default, and that for openvswitch users it does not make any
sense.

So, stop cluttering the live iptables ruleset.

This functionality seems to be introduced before 2004 and since then it
has never got some additional love.

It would be nice to have a proper discussion upstream about how Xen
could provide some anti mac/ip spoofing in the dom0. It does not seem to
be a trivial thing to do, since it requires having quite some knowledge
about what the domU is allowed to do or not (e.g. a domU can be a
router...).

Fix empty fields in first hypervisor log line

Instead of:

    (XEN) Xen version 4.11.1 (Debian )
    (@)
    (gcc (Debian 8.2.0-13) 8.2.0) debug=n
    Thu Jan  3 19:08:37 UTC 2019

I'd like to see:

    (XEN) Xen version 4.11.1 (Debian 4.11.1-1~)
    (pkg-xen-devel@lists.alioth.debian.org)
    (gcc (Debian 8.2.0-13) 8.2.0) debug=n
    Thu Jan  3 22:44:00 CET 2019

The substitution was broken since the great packaging refactoring,
because the directory in which the build is done changed.

Also, use the Maintainer address from debian/control instead of the most
recent changelog entry. If someone wants to use the address to ask a
question, they will end up at the team mailing list, which is better
than an individual person.

docs/man/xen-vbd-interface.7: Provide properly-formatted NAME section

This manpage was omitted from
   docs/man: Provide properly-formatted NAME sections
because I was previously building with markdown not installed.

Signed-off-by: Ian Jackson <ian.jackson@citrix.com>

shim: Provide separate install-shim target

When building on a 32-bit userland, the user wants to build 32-bit
tools and a 64-bit hypervisor.  This involves setting XEN_TARGET_ARCH
to different values for the tools build and the hypervisor build.

So the user must invoke the tools build and the hypervisor build
separately.

However, although the shim is done by the tools/firmware Makefile, its
bitness needs to be the same as the hypervisor, not the same as the
tools.  When run with XEN_TARGET_ARCH=x86_32, it it skipped, which is
wrong.

So the user must invoke the shim build separately.  This can be done
with
   make -C tools/firmware/xen-dir XEN_TARGET_ARCH=x86_64

However, tools/firmware/xen-dir has no `install' target.  The
installation of all `firmware' is done in tools/firmware/Makefile.  It
might be possible to fix this, but it is not trivial.  For example,
the definitions of INST_DIR and DEBG_DIR would need to be copied, as
would an appropriate $(INSTALL_DIR) call.

For now, provide an `install-shim' target in tools/firmware/Makefile.

This has to be called from `install' of course.  We can't make it
a dependency of `install' because it might be run before `all' has
completed.  We could make it depend on a `shim' target but such
a target is nearly impossible to write because everything is done by
the inflexible subdir-$@ machinery.

The overally result of this patch is that existing make invocations
work as before.  But additionally, the user can say
  make -C tools/firmware install-shim XEN_TARGET_ARCH=x86_64
to install the shim.  The user must have built it already.
Unlike the build rune, this install-rune is properly conditional
so it is OK to call on ARM.

What a mess.

Signed-off-by: Ian Jackson <ijackson@chiark.greenend.org.uk>

tools/firmware/Makfile: Respect caller's CONFIG_PV_SHIM

This makes it easier to disable the shim build.  (In Debian we need to
build the shim separately because it needs different compiler flags
and a different XEN_COMPILE_ARCH.

Signed-off-by: Ian Jackson <ijackson@chiark.greenend.org.uk>

.gitignore: Add configure output which we always delete and regenerate

Signed-off-by: Ian Jackson <ian.jackson@citrix.com>

autoconf: Provide libexec_libdir_suffix

This is going to be used to put libfsimage.so into a path containing
the multiarch triplet.

Signed-off-by: Ian Jackson <ian.jackson@citrix.com>

tools-libfsimage-prefix.diff

\o/

Do not build the instruction emulator

Signed-off-by: Ian Jackson <ian.jackson@citrix.com>

tools/tests/x86_emulator: Pass -no-pie -fno-pic to gcc on x86_32

The current build fails with GCC6 on Debian sid i386 (unstable):

 /tmp/ccqjaueF.s: Assembler messages:
 /tmp/ccqjaueF.s:3713: Error: missing or invalid displacement expression `vmovd_to_reg_len@GOT'

This is due to the combination of GCC6, and Debian's decision to
enable some hardening flags by default (to try to make runtime
addresses less predictable):
  https://wiki.debian.org/Hardening/PIEByDefaultTransition

This is of no benefit for the x86 instruction emulator test, which is
a rebuild of the emulator code for testing purposes only.  So pass
options to disable this.

These options will be no-ops if they are the same as the compiler
default.

On amd64, the -fno-pic breaks the build in a different way.  So do
this only on i386.

Signed-off-by: Ian Jackson <ian.jackson@citrix.com>
CC: Jan Beulich <jbeulich@suse.com>
CC: Andrew Cooper <andrew.cooper3@citrix.com>
Gbp-Pq: Topic misc
Gbp-Pq: Name toolstestsx86_emulator-pass--no-pie--fno.patch

Remove static solaris support from pygrub

Patch-Name: tools-pygrub-remove-static-solaris-support

Gbp-Pq: Topic misc
Gbp-Pq: Name tools-pygrub-remove-static-solaris-support

Do not ship COPYING into /usr/include

This is not wanted in Debian.  COPYING ends up in
/usr/share/doc/xen-*copyright.

Patch-Name: tools-include-no-COPYING.diff

Signed-off-by: Ian Jackson <ian.jackson@citrix.com>

config-prefix.diff

Patch-Name: config-prefix.diff

Gbp-Pq: Topic prefix-abiname
Gbp-Pq: Name config-prefix.diff

version

Delete configure output

These autogenerated files are not useful in Debian; dh_autoreconf will
regenerate them.

If this patch does not apply when rebasing, you can simply delete the
files again.

Signed-off-by: Ian Jackson <ian.jackson@citrix.com>

Delete config.sub and config.guess

dh_autoreconf will provide these back.

If this patch does not apply when rebasing, you can simply delete the
files again.

Signed-off-by: Ian Jackson <ian.jackson@citrix.com>

debian/changelog: All the things for 4.14.0-1~exp1

We're going to first do an upload to experimental. Either the same thing
goes as 4.14.0-1 to unstable later, or maybe it'll be something else,
but at least we have the possibility when adding ~exp1 now.

Signed-off-by: Hans van Kranenburg <hans@knorrie.org>

debian/rules: Add --host to tools configure target

Without this, we'll be building tools for the build machine, not the host
machine.

Signed-off-by: Elliott Mitchell <ehem+debian@m5p.com>
Reviewed-by: Ian Jackson <iwj@xenproject.org>

debian/rules: Combine shared Make args

The original author of debian/rules seemed to have planned to make use
of $(make_args_common), but never got to sharing combined values.  Since
some values are shareable, make use of the shared args.

Signed-off-by: Elliott Mitchell <ehem+debian@m5p.com>
Reviewed-by: Ian Jackson <iwj@xenproject.org>

debian/control: Fix python dependency

Debian's Xen build actually has two distinct Python dependencies.  The
build process itself needs Python's build machine runtime available to
run portions of the build written in Python.  The build process also
needs the host machine libraries in order to link Xen's Python libraries.

Signed-off-by: Elliott Mitchell <ehem+debian@m5p.com>
Acked-by: Hans van Kranenburg <hans@knorrie.org>

debian/control: Standards-Version: 4.5.0

I read the upgrading checklist for changes after 3.9.4 up to 4.5.0 and I
don't see shocking things that we really need to do.

So, bump it.

Signed-off-by: Hans van Kranenburg <hans@knorrie.org>

d/xen-utils-common.xen.init: use /run instead of /var/run

/var/run has been a symlink to /run for ages, and since Stretch it's
guaranteed to be available. Adapt the paths in here to use /run
directly.

Debian Policy Manual v4.0.0, Released May, 2017 checklist says:

    9.1.1 The stable release of Debian supports /run, so packages may
    now assume that it exists and do not need any special dependency on
    a version of initscripts.

Signed-off-by: Hans van Kranenburg <hans@knorrie.org>

d/xen-utils-V.lintian-overrides.vsn-in: s/fsimage/xenfsimage/

I missed these ones in "debian/: Follow fsimage -> xenfsimage renaming"

Signed-off-by: Hans van Kranenburg <hans@knorrie.org>

d/xen-utils-V.lintian-overrides.vsn-in: fix rpath override

Lintian complains:

    E: xen-utils-4.14: custom-library-search-path usr/lib/xen-4.14/lib/python/xenfsimage.cpython-38-x86_64-linux-gnu.so /usr/lib/xen-4.14/lib/x86_64-linux-gnu
    N:
    N:    The binary or shared library sets RPATH or RUNPATH. This overrides the
    N:    normal library search path, possibly interfering with local policy and
    N:    causing problems for multilib, among other issues.
    N:
    N:    The only time a binary or shared library in a Debian package should set
    N:    RPATH or RUNPATH is if it is linked to private shared libraries in the
    N:    same package. In that case, place those private shared libraries in
    N:    /usr/lib/<package>. Libraries used by binaries in other packages should
    N:    be placed in /lib or /usr/lib as appropriate, with a proper SONAME, in
    N:    which case RPATH/RUNPATH is unnecessary.
    N:
    N:    To fix this problem, look for link lines like:
    N:        gcc test.o -o test -Wl,--rpath,/usr/local/lib
    N:    or
    N:        gcc test.o -o test -R/usr/local/lib
    N:    and remove the -Wl,--rpath or -R argument. You can also use the chrpath
    N:    utility to remove the RPATH.
    N:
    N:    Refer to https://wiki.debian.org/RpathIssue for details.
    N:
    N:    Severity: error
    N:
    N:    Check: binaries

    W: xen-utils-4.14: mismatched-override custom-library-search-path usr/lib/xen-4.14/lib/python/xenfsimage.so /usr/lib/xen-4.14/lib/x86_64-linux-gnu
    N:
    N:    The named tag could have been silenced but the context specified with
    N:    the override did not match.
    N:
    N:    Lintian may now provide a different context for the tag, or something
    N:    could have changed in a new version of your package. Either way,
    N:    overrides work best when you require only little context.
    N:
    N:    You can use wildcards, such as &ast; or &quest; in the context to makes
    N:    a match more likely.
    N:
    N:    Please remove or adjust the override, whichever suits your purpose.
    N:
    N:    Severity: warning
    N:
    N:    Check: lintian

The target file has a new name, with cpython-blurb in it. Wildcard that
part.

Signed-off-by: Hans van Kranenburg <hans@knorrie.org>

debian/control: drop autotools-dev build dependency

Lintian complains:

    W: xen source: useless-autoreconf-build-depends autotools-dev
    N:
    N:    Since compatibility level 10, debhelper enables the autoreconf sequence
    N:    by default.
    N:
    N:    It is therefore not necessary to specify build-dependencies on
    N:    dh-autoreconf or autotools-dev and they can be removed.
    N:
    N:    Severity: warning
    N:
    N:    Check: debhelper

So, drop it.

Signed-off-by: Hans van Kranenburg <hans@knorrie.org>

debian/control: remove XS-Python-Version

Lintian complains:

    W: xen source: python-version-current-is-deprecated XS-Python-Version
    N:
    N:    The use of "current" in the Python-Version or Python3-Version field is
    N:    deprecated.
    N:
    N:    Refer to Debian Python Policy section 3.4 (Specifying Supported
    N:    Versions) for details.
    N:
    N:    Severity: warning
    N:
    N:    Check: languages/python

So, drop it.

We could replace it with X-Python3-Version, but that documentation
says...

    "The optional X-Python3-Version field specifies the versions of
    Python 3 supported. When not specified, it defaults to all currently
    supported Python 3 versions."

...and I think that's fine for the python code included here. Actually,
I'm not sure, but yolo.

Signed-off-by: Hans van Kranenburg <hans@knorrie.org>

d/xen-hypervisor-V-F.lintian-overrides.vsn-in: fix override

First of all, debug-package-should-be-named-dbg does not exist any more,
but debug-suffix-not-dbg does, change it.

Lintian complains:

    W: xen-hypervisor-4.14-amd64: debug-suffix-not-dbg usr/lib/debug/xen-4.14.0.efi.map.gz
    N:
    N:    This package provides at least one file in /usr/lib/debug, which is
    N:    intended for detached debugging symbols, but the package name does not
    N:    end in "-dbg". Detached debugging symbols should be put into a separate
    N:    package, Priority: extra, with a package name ending in "-dbg".
    N:
    N:    Refer to Debian Developer's Reference section 6.7.9 (Best practices for
    N:    debug packages) for details.
    N:
    N:    Severity: warning
    N:
    N:    Check: files/debug

...and also complains:

    W: xen-hypervisor-4.14-amd64: mismatched-override debug-suffix-not-dbg usr/lib/debug/xen-*-pre.efi.map.gz
    N:
    N:    The named tag could have been silenced but the context specified with
    N:    the override did not match.
    N:
    N:    Lintian may now provide a different context for the tag, or something
    N:    could have changed in a new version of your package. Either way,
    N:    overrides work best when you require only little context.
    N:
    N:    You can use wildcards, such as &ast; or &quest; in the context to makes
    N:    a match more likely.
    N:
    N:    Please remove or adjust the override, whichever suits your purpose.
    N:
    N:    Severity: warning
    N:
    N:    Check: lintian

So, secondly, fix this by dropping the -pre part which prevents it from
matching.

Signed-off-by: Hans van Kranenburg <hans@knorrie.org>

debian/control: xen-doc: add ${misc:Depends}

Lintian complains:

    W: xen source: debhelper-but-no-misc-depends xen-doc
    N:
    N:    The source package uses debhelper, but it does not include
    N:    ${misc:Depends} in the given binary package's debian/control entry. Any
    N:    debhelper command may add dependencies to ${misc:Depends} that are
    N:    required for the work that it does, so recommended best practice is to
    N:    always add ${misc:Depends} to the dependencies of each binary package if
    N:    debhelper is in use.
    N:
    N:    Refer to the debhelper(7) manual page for details.
    N:
    N:    Severity: warning
    N:
    N:    Check: debhelper

Signed-off-by: Hans van Kranenburg <hans@knorrie.org>

debian/control: fix xen-utils-4.14 python3 dependency

Lintian complains:

    E: xen-utils-4.14: python-script-but-no-python-dep usr/lib/xen-4.14/bin/convert-legacy-stream #!/usr/bin/python3
    N:
    N:    Packages with Python scripts should depend on the package python. Those
    N:    with scripts that specify a specific version of Python must depend,
    N:    recommend or suggest on that version of Python (exactly).
    N:
    N:    For example, if a script in the package uses #!/usr/bin/python, the
    N:    package needs a dependency on python. If a script uses
    N:    #!/usr/bin/python2.6, the package needs a dependency on python2.6. A
    N:    dependency on python (>= 2.6) is not correct, since later versions of
    N:    Python may not provide the /usr/bin/python2.6 binary.
    N:
    N:    If you are using debhelper, adding ${python3:Depends} or
    N:    ${python:Depends} to the Depends field and ensuring dh_python2 or
    N:    dh_python3 are run during the build should take care of adding the
    N:    correct dependency.
    N:
    N:    In some cases a weaker relationship, such as Suggests or Recommends,
    N:    will be more appropriate.
    N:
    N:    Severity: error
    N:
    N:    Check: scripts
    N:
    E: xen-utils-4.14: python-script-but-no-python-dep usr/lib/xen-4.14/bin/pygrub #!/usr/bin/python3
    E: xen-utils-4.14: python-script-but-no-python-dep usr/lib/xen-4.14/bin/verify-stream-v2 #!/usr/bin/python3
    E: xen-utils-4.14: python-script-but-no-python-dep usr/lib/xen-4.14/bin/xenpvnetboot #!/usr/bin/python3

The xen-utils-4.14 is indeed missing the python3 dependency. This is
probably because of the dh_python3 override that makes it skip dealing
with the ${python3:Depends} dependency:

    # dh_python3 does not know to look in the funny directory where
    # we put the versioned /usr/lib files including some python scripts.
    override_dh_python3:
    dh_python3
    dh_python3 -pxen-utils-$(upstream_version) \
    usr/lib/xen-$(upstream_version)/bin

So, just hardcode python3 as dependency, yolo.

Signed-off-by: Hans van Kranenburg <hans@knorrie.org>

xen-utils-V.postinst.vsn-in: cosmetics

There were some tabs here, convert them to spaces like in the rest of
the file.

Signed-off-by: Hans van Kranenburg <hans@knorrie.org>

xen-utils-V scripts: remove update-alternatives

This has been in here for ages. I guess that we can remove it now.

Signed-off-by: Hans van Kranenburg <hans@knorrie.org>

debian/control: s/libncurses5-dev/libncurses-dev/

libncurses5-dev is a transitional package for libncurses-dev

Signed-off-by: Hans van Kranenburg <hans@knorrie.org>

debian/rules: Avoid using $(PWD) variable.

Fixes: lintian: debian-rules-should-not-use-pwd
See-also: https://lintian.debian.org/tags/debian-rules-should-not-use-pwd.html

debian/pycompat: remove obsolete file.

Fixes: lintian: debian-pycompat-is-obsolete
See-also: https://lintian.debian.org/tags/debian-pycompat-is-obsolete.html

debian/changelog: trim trailing whitespace.

Fixes: lintian: file-contains-trailing-whitespace
See-also: https://lintian.debian.org/tags/file-contains-trailing-whitespace.html

d/scripts/xen-init-list: python3 and remove cruft

This little script is used by the xendomains init script. See new
comment inside for more info.

* Change it to python3
* Remove all the obsolete xend related SXP cruft
* Remove all the overly obsessed object orientedness

Signed-off-by: Hans van Kranenburg <hans@knorrie.org>

d/scripts/xen-init-name: python3 and remove cruft

This little script is used by the xendomains init script. See new
comment inside for more info.

* Change it to python3
* Remove all the obsolete xend related SXP cruft
* Remove all the overly obsessed object orientedness

Signed-off-by: Hans van Kranenburg <hans@knorrie.org>

debian/libxenstore3.0.symbols: drop xprintf

Exporting this was always a mistake.

The build will fail with:

  gcc xs_tdb_dump.o utils.o tdb.o talloc.o    -Wl,-z,relro -Wl,-z,now  -o xs_tdb_dump
  /usr/bin/ld: utils.o:./tools/xenstore/utils.h:27: multiple definition of
    `xprintf'; xs_tdb_dump.o:./tools/xenstore/utils.h:27: first defined here

Closes: #968965
Signed-off-by: Ian Jackson <ian.jackson@citrix.com>

debian/control: add libxenhypfs[1]

This is a new library in upstream.  It has a stable ABI and a proper
soname, currently "1".

Signed-off-by: Ian Jackson <ian.jackson@citrix.com>

debian/{rules,control}: switch to python 3

Debian Bullseye is going to release without python 2.

Signed-off-by: Hans van Kranenburg <hans@knorrie.org>

debian/control: add flex, bison

The build uses them apparently, now, and we didn't have it available, so
it would FTBFS.

Signed-off-by: Hans van Kranenburg <hans@knorrie.org>

debian/control: cleanup Uploaders

Signed-off-by: Hans van Kranenburg <hans@knorrie.org>

Update changelog for new upstream 4.14.0

[git-debrebase changelog: new upstream 4.14.0]

Update to upstream 4.14.0

[git-debrebase anchor: new upstream 4.14.0, merge]

README, Makefile: Xen 4.14.0 release

Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>

Config.mk: Nail subtrees to the Xen 4.14.0 release tags

Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>

SUPPORT.md: Set version and release/support dates

Signed-off-by: Paul Durrant <pdurrant@amazon.com>
Acked-by: Julien Grall <jgrall@amazon.com>
Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
Acked-by: Jan Beulich <jbeulich@suse.com>

d/xen-utils-common.xen.init: multi-version comment

Having the init script in a -common package (of which the version is
installed that matches the newest installed versioned other xen
packages) means that it also has to be able to deal with older Xen
versions.

Add a little reminder of this fact, because this can be a bit of a
surprise if you didn't realize yet.

Signed-off-by: Hans van Kranenburg <hans@knorrie.org>

debian/rules: Drop redundant sequence numbers in dh_installinit

Closes: #939560 (3/3)
Reported-by: Guillem Jover <guillem@debian.org>
Signed-off-by: Ian Jackson <ian.jackson@citrix.com>

debian/rules: Improve comment about hardening options

Closes: #939560 (2/3)
Reported-by: Guillem Jover <guillem@debian.org>
Signed-off-by: Ian Jackson <ian.jackson@citrix.com>

debian/rules: Set DEB_BUILD_MAINT_OPTIONS in shell

This makes these hardening options actually effective.

Closes: #939560 (1/3)
Reported-by: Guillem Jover <guillem@debian.org>
Signed-off-by: Ian Jackson <ian.jackson@citrix.com>

debian/xen-utils-V.*: Use @version@ instead of hardcoded version

I guess this doesn't need a lot of extra explanation...

Signed-off-by: Hans van Kranenburg <hans@knorrie.org>

debian/: Follow fsimage -> xenfsimage renaming

In the upstream code, the name of this library has been changed to make
it more Xen-specific. Also filesystem paths have changed. Update
accordingly.

Signed-off-by: Hans van Kranenburg <hans@knorrie.org>

debian/rules: remove pkgconfig stuff

These files are not present any more. Remove the obsolete lines that
would place them somewhere.

Signed-off-by: Hans van Kranenburg <hans@knorrie.org>

debian/control: adjust to 4.14

Update changelog for new upstream 4.14.0~rc6+2-g23fe1b8d51

[git-debrebase changelog: new upstream 4.14.0~rc6+2-g23fe1b8d51]

Update to upstream 4.14.0~rc6+2-g23fe1b8d51

[git-debrebase anchor: new upstream 4.14.0~rc6+2-g23fe1b8d51, merge]

Revert "SUPPORT.md: Set version and release/support dates"

This reverts commit e4670f8b045b11a524171b119d9d4a20bf643367.

SUPPORT.md: Set version and release/support dates

Signed-off-by: Paul Durrant <pdurrant@amazon.com>
Acked-by: Julien Grall <jgrall@amazon.com>

SUPPORT.md: Spell Experimental correctly

Signed-off-by: Julien Grall <jgrall@amazon.com>
Acked-by: Andrew Cooper <andrew.cooper3@citrix.com>
Release-acked-by: Paul Durrant <paul@xen.org>
(cherry picked from commit 139ce42388c3fe7096a09b3d397250fe14906809)

docs: Replace non-UTF-8 character in hypfs-paths.pandoc

From the docs cronjob on xenbits:

  /usr/bin/pandoc --number-sections --toc --standalone misc/hypfs-paths.pandoc --output html/misc/hypfs-paths.html
  pandoc: Cannot decode byte '\x92': Data.Text.Internal.Encoding.decodeUtf8: Invalid UTF-8 stream
  make: *** [Makefile:236: html/misc/hypfs-paths.html] Error 1

Fixes: 5a4a411bde4 ("docs: specify stability of hypfs path documentation")
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Release-acked-by: Paul Durrant <paul@xen.org>
(cherry picked from commit 9ffdda96d9e7c3d9c7a5bbe2df6ab30f63927542)

docs: specify stability of hypfs path documentation

In docs/misc/hypfs-paths.pandoc the supported paths in the hypervisor
file system are specified. Make it more clear that path availability
might change, e.g. due to scope widening or narrowing (e.g. being
limited to a specific architecture).

Signed-off-by: Juergen Gross <jgross@suse.com>
Acked-by: Jan Beulich <jbeulich@suse.com>
Release-acked-by: Paul Durrant <paul@xen.org>
master commit: 5a4a411bde4f73ff8ce43d6e52b77302973e8f68
master date: 2020-07-20 13:38:00 +0200

x86: restore pv_rtc_handler() invocation

This was lost when making the logic accessible to PVH Dom0.

While doing so make the access to the global function pointer safe
against races (as noticed by Roger): The only current user wants to be
invoked just once (but can tolerate to be invoked multiple times),
zapping the pointer at that point.

Fixes: 835d8d69d96a ("x86/rtc: provide mediated access to RTC for PVH dom0")
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Roger Pau Monné <roger.pau@citrix.com>
Release-acked-by: Paul Durrant <paul@xen.org>
master commit: f8fe3c07363d11fc81d8e7382dbcaa357c861569
master date: 2020-07-15 15:46:30 +0200

Branch 4.14: Turn off debug on this stable branch

Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>

SUPPORT.md: Set release notes link

Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>

pvcalls: Document correctly and explicitely the padding for all arches

The specification of pvcalls suggests there is padding for 32-bit x86 at
the end of most the structure. However, they are not described in in the
public header.

Because of that all the structures would have a different size between
32-bit x86 and 64-bit x86.

For all the other architectures supported (Arm and 64-bit x86), the
structure have the sames sizes because they contain implicit padding
thanks to the 64-bit alignment of the field uint64_t field.

Given the specification is authoritative, the padding will now be the
same for all architectures. The potential breakage of compatibility is
ought to be fine as pvcalls is still a tech preview.

Signed-off-by: Julien Grall <jgrall@amazon.com>
Reviewed-by: Juergen Gross <jgross@suse.com>
Reviewed-by: Stefano Stabellini <sstabellini@kernel.org>
Release-acked-by: Paul Durrant <paul@xen.org>
Signed-off-by: Stefano Stabellini <stefano.stabellini@xilinx.com>

pvcalls: Clearly spell out that the header is just a reference

A recent thread on xen-devel [1] pointed out that the header was
provided as a reference for the specification.

Unfortunately, this was never written down in xen.git so for an external
user (or a reviewer) it is not clear whether the spec or the header
should be followed when there is a conflict.

To avoid more confusion, a paragraph is added at the top of the header
to clearly spell out it is only provided for reference.

[1] https://lore.kernel.org/xen-devel/alpine.DEB.2.21.2006151343430.9074@sstabellini-ThinkPad-T480s/

Signed-off-by: Julien Grall <jgrall@amazon.com>
Reviewed-by: Juergen Gross <jgross@suse.com>
Acked-by: Stefano Stabellini <sstabellini@kernel.org>
Release-acked-by: Paul Durrant <paul@xen.org>
Signed-off-by: Stefano Stabellini <stefano.stabellini@xilinx.com>

debian/changelog: finish 4.11.4+24-gddaaccbbab-1

Update changelog for new upstream 4.11.4+24-gddaaccbbab

[git-debrebase changelog: new upstream 4.11.4+24-gddaaccbbab]

Update to upstream 4.11.4+24-gddaaccbbab

[git-debrebase anchor: new upstream 4.11.4+24-gddaaccbbab, merge]

xen: Check the alignment of the offset pased via VCPUOP_register_vcpu_info

Currently a guest is able to register any guest physical address to use
for the vcpu_info structure as long as the structure can fits in the
rest of the frame.

This means a guest can provide an address that is not aligned to the
natural alignment of the structure.

On Arm 32-bit, unaligned access are completely forbidden by the
hypervisor. This will result to a data abort which is fatal.

On Arm 64-bit, unaligned access are only forbidden when used for atomic
access. As the structure contains fields (such as evtchn_pending_self)
that are updated using atomic operations, any unaligned access will be
fatal as well.

While the misalignment is only fatal on Arm, a generic check is added
as an x86 guest shouldn't sensibly pass an unaligned address (this
would result to a split lock).

This is XSA-327.

Reported-by: Julien Grall <jgrall@amazon.com>
Signed-off-by: Julien Grall <jgrall@amazon.com>
Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Stefano Stabellini <sstabellini@kernel.org>
master commit: 3fdc211b01b29f252166937238efe02d15cb5780
master date: 2020-07-07 14:41:00 +0200

x86/ept: flush cache when modifying PTEs and sharing page tables

Modifications made to the page tables by EPT code need to be written
to memory when the page tables are shared with the IOMMU, as Intel
IOMMUs can be non-coherent and thus require changes to be written to
memory in order to be visible to the IOMMU.

In order to achieve this make sure data is written back to memory
after writing an EPT entry when the recalc bit is not set in
atomic_write_ept_entry. If such bit is set, the entry will be
adjusted and atomic_write_ept_entry will be called a second time
without the recalc bit set. Note that when splitting a super page the
new tables resulting of the split should also be written back.

Failure to do so can allow devices behind the IOMMU access to the
stale super page, or cause coherency issues as changes made by the
processor to the page tables are not visible to the IOMMU.

This allows to remove the VT-d specific iommu_pte_flush helper, since
the cache write back is now performed by atomic_write_ept_entry, and
hence iommu_iotlb_flush can be used to flush the IOMMU TLB. The newly
used method (iommu_iotlb_flush) can result in less flushes, since it
might sometimes be called rightly with 0 flags, in which case it
becomes a no-op.

This is part of XSA-321.

Signed-off-by: Roger Pau Monné <roger.pau@citrix.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
master commit: c23274fd0412381bd75068ebc9f8f8c90a4be748
master date: 2020-07-07 14:40:11 +0200

vtd: optimize CPU cache sync

Some VT-d IOMMUs are non-coherent, which requires a cache write back
in order for the changes made by the CPU to be visible to the IOMMU.
This cache write back was unconditionally done using clflush, but there are
other more efficient instructions to do so, hence implement support
for them using the alternative framework.

This is part of XSA-321.

Signed-off-by: Roger Pau Monné <roger.pau@citrix.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
master commit: a64ea16522a73a13a0d66cfa4b66a9d3b95dd9d6
master date: 2020-07-07 14:39:54 +0200

x86/alternative: introduce alternative_2

It's based on alternative_io_2 without inputs or outputs but with an
added memory clobber.

This is part of XSA-321.

Signed-off-by: Roger Pau Monné <roger.pau@citrix.com>
Acked-by: Jan Beulich <jbeulich@suse.com>
master commit: 23570bce00ee6ba2139ece978ab6f03ff166e21d
master date: 2020-07-07 14:39:25 +0200

vtd: don't assume addresses are aligned in sync_cache

Current code in sync_cache assume that the address passed in is
aligned to a cache line size. Fix the code to support passing in
arbitrary addresses not necessarily aligned to a cache line size.

This is part of XSA-321.

Reported-by: Jan Beulich <jbeulich@suse.com>
Signed-off-by: Roger Pau Monné <roger.pau@citrix.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
master commit: b6d9398144f21718d25daaf8d72669a75592abc5
master date: 2020-07-07 14:39:05 +0200

x86/iommu: introduce a cache sync hook

The hook is only implemented for VT-d and it uses the already existing
iommu_sync_cache function present in VT-d code. The new hook is
added so that the cache can be flushed by code outside of VT-d when
using shared page tables.

Note that alloc_pgtable_maddr must use the now locally defined
sync_cache function, because IOMMU ops are not yet setup the first
time the function gets called during IOMMU initialization.

No functional change intended.

This is part of XSA-321.

Signed-off-by: Roger Pau Monné <roger.pau@citrix.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
master commit: 91526b460e5009fc56edbd6809e66c327281faba
master date: 2020-07-07 14:38:34 +0200

vtd: prune (and rename) cache flush functions

Rename __iommu_flush_cache to iommu_sync_cache and remove
iommu_flush_cache_page. Also remove the iommu_flush_cache_entry
wrapper and just use iommu_sync_cache instead. Note the _entry suffix
was meaningless as the wrapper was already taking a size parameter in
bytes. While there also constify the addr parameter.

No functional change intended.

This is part of XSA-321.

Signed-off-by: Roger Pau Monné <roger.pau@citrix.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
master commit: 62298825b9a44f45761acbd758138b5ba059ebd1
master date: 2020-07-07 14:38:13 +0200

vtd: improve IOMMU TLB flush

Do not limit PSI flushes to order 0 pages, in order to avoid doing a
full TLB flush if the passed in page has an order greater than 0 and
is aligned. Should increase the performance of IOMMU TLB flushes when
dealing with page orders greater than 0.

This is part of XSA-321.

Signed-off-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Roger Pau Monné <roger.pau@citrix.com>
master commit: 5fe515a0fede07543f2a3b049167b1fd8b873caf
master date: 2020-07-07 14:37:46 +0200

x86/ept: atomically modify entries in ept_next_level

ept_next_level was passing a live PTE pointer to ept_set_middle_entry,
which was then modified without taking into account that the PTE could
be part of a live EPT table. This wasn't a security issue because the
pages returned by p2m_alloc_ptp are zeroed, so adding such an entry
before actually initializing it didn't allow a guest to access
physical memory addresses it wasn't supposed to access.

This is part of XSA-328.

Reported-by: Jan Beulich <jbeulich@suse.com>
Signed-off-by: Roger Pau Monné <roger.pau@citrix.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
master commit: bc3d9f95d661372b059a5539ae6cb1e79435bb95
master date: 2020-07-07 14:37:12 +0200

x86/EPT: ept_set_middle_entry() related adjustments

ept_split_super_page() wants to further modify the newly allocated
table, so have ept_set_middle_entry() return the mapped pointer rather
than tearing it down and then getting re-established right again.

Similarly ept_next_level() wants to hand back a mapped pointer of
the next level page, so re-use the one established by
ept_set_middle_entry() in case that path was taken.

Pull the setting of suppress_ve ahead of insertion into the higher level
table, and don't have ept_split_super_page() set the field a 2nd time.

This is part of XSA-328.

Signed-off-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Roger Pau Monné <roger.pau@citrix.com>
master commit: 1104288186ee73a7f9bfa41cbaa5bb7611521028
master date: 2020-07-07 14:36:52 +0200

x86/shadow: correct an inverted conditional in dirty VRAM tracking

This originally was "mfn_x(mfn) == INVALID_MFN". Make it like this
again, taking the opportunity to also drop the unnecessary nearby
braces.

This is XSA-319.

Fixes: 246a5a3377c2 ("xen: Use a typesafe to define INVALID_MFN")
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
master commit: 23a216f99d40fbfbc2318ade89d8213eea6ba1f8
master date: 2020-07-07 14:36:24 +0200

xen/common: event_channel: Don't ignore error in get_free_port()

Currently, get_free_port() is assuming that the port has been allocated
when evtchn_allocate_port() is not return -EBUSY.

However, the function may return an error when:
    - We exhausted all the event channels. This can happen if the limit
    configured by the administrator for the guest ('max_event_channels'
    in xl cfg) is higher than the ABI used by the guest. For instance,
    if the guest is using 2L, the limit should not be higher than 4095.
    - We cannot allocate memory (e.g Xen has not more memory).

Users of get_free_port() (such as EVTCHNOP_alloc_unbound) will validly
assuming the port was valid and will next call evtchn_from_port(). This
will result to a crash as the memory backing the event channel structure
is not present.

Fixes: 368ae9a05fe ("xen/pvshim: forward evtchn ops between L0 Xen and L2 DomU")
Signed-off-by: Julien Grall <jgrall@amazon.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
master commit: 2e9c2bc292231823a3a021d2e0a9f1956bf00b3c
master date: 2020-07-07 14:35:36 +0200

xen: Check the alignment of the offset pased via VCPUOP_register_vcpu_info

Currently a guest is able to register any guest physical address to use
for the vcpu_info structure as long as the structure can fits in the
rest of the frame.

This means a guest can provide an address that is not aligned to the
natural alignment of the structure.

On Arm 32-bit, unaligned access are completely forbidden by the
hypervisor. This will result to a data abort which is fatal.

On Arm 64-bit, unaligned access are only forbidden when used for atomic
access. As the structure contains fields (such as evtchn_pending_self)
that are updated using atomic operations, any unaligned access will be
fatal as well.

While the misalignment is only fatal on Arm, a generic check is added
as an x86 guest shouldn't sensibly pass an unaligned address (this
would result to a split lock).

This is XSA-327.

Reported-by: Julien Grall <jgrall@amazon.com>
Signed-off-by: Julien Grall <jgrall@amazon.com>
Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Stefano Stabellini <sstabellini@kernel.org>

x86/ept: flush cache when modifying PTEs and sharing page tables

Modifications made to the page tables by EPT code need to be written
to memory when the page tables are shared with the IOMMU, as Intel
IOMMUs can be non-coherent and thus require changes to be written to
memory in order to be visible to the IOMMU.

In order to achieve this make sure data is written back to memory
after writing an EPT entry when the recalc bit is not set in
atomic_write_ept_entry. If such bit is set, the entry will be
adjusted and atomic_write_ept_entry will be called a second time
without the recalc bit set. Note that when splitting a super page the
new tables resulting of the split should also be written back.

Failure to do so can allow devices behind the IOMMU access to the
stale super page, or cause coherency issues as changes made by the
processor to the page tables are not visible to the IOMMU.

This allows to remove the VT-d specific iommu_pte_flush helper, since
the cache write back is now performed by atomic_write_ept_entry, and
hence iommu_iotlb_flush can be used to flush the IOMMU TLB. The newly
used method (iommu_iotlb_flush) can result in less flushes, since it
might sometimes be called rightly with 0 flags, in which case it
becomes a no-op.

This is part of XSA-321.

Signed-off-by: Roger Pau Monné <roger.pau@citrix.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>

vtd: optimize CPU cache sync

Some VT-d IOMMUs are non-coherent, which requires a cache write back
in order for the changes made by the CPU to be visible to the IOMMU.
This cache write back was unconditionally done using clflush, but there are
other more efficient instructions to do so, hence implement support
for them using the alternative framework.

This is part of XSA-321.

Signed-off-by: Roger Pau Monné <roger.pau@citrix.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>

x86/alternative: introduce alternative_2

It's based on alternative_io_2 without inputs or outputs but with an
added memory clobber.

This is part of XSA-321.

Signed-off-by: Roger Pau Monné <roger.pau@citrix.com>
Acked-by: Jan Beulich <jbeulich@suse.com>

vtd: don't assume addresses are aligned in sync_cache

Current code in sync_cache assume that the address passed in is
aligned to a cache line size. Fix the code to support passing in
arbitrary addresses not necessarily aligned to a cache line size.

This is part of XSA-321.

Reported-by: Jan Beulich <jbeulich@suse.com>
Signed-off-by: Roger Pau Monné <roger.pau@citrix.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>

x86/iommu: introduce a cache sync hook

The hook is only implemented for VT-d and it uses the already existing
iommu_sync_cache function present in VT-d code. The new hook is
added so that the cache can be flushed by code outside of VT-d when
using shared page tables.

Note that alloc_pgtable_maddr must use the now locally defined
sync_cache function, because IOMMU ops are not yet setup the first
time the function gets called during IOMMU initialization.

No functional change intended.

This is part of XSA-321.

Signed-off-by: Roger Pau Monné <roger.pau@citrix.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>

vtd: prune (and rename) cache flush functions

Rename __iommu_flush_cache to iommu_sync_cache and remove
iommu_flush_cache_page. Also remove the iommu_flush_cache_entry
wrapper and just use iommu_sync_cache instead. Note the _entry suffix
was meaningless as the wrapper was already taking a size parameter in
bytes. While there also constify the addr parameter.

No functional change intended.

This is part of XSA-321.

Signed-off-by: Roger Pau Monné <roger.pau@citrix.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>

vtd: improve IOMMU TLB flush

Do not limit PSI flushes to order 0 pages, in order to avoid doing a
full TLB flush if the passed in page has an order greater than 0 and
is aligned. Should increase the performance of IOMMU TLB flushes when
dealing with page orders greater than 0.

This is part of XSA-321.

Signed-off-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Roger Pau Monné <roger.pau@citrix.com>

x86/ept: atomically modify entries in ept_next_level

ept_next_level was passing a live PTE pointer to ept_set_middle_entry,
which was then modified without taking into account that the PTE could
be part of a live EPT table. This wasn't a security issue because the
pages returned by p2m_alloc_ptp are zeroed, so adding such an entry
before actually initializing it didn't allow a guest to access
physical memory addresses it wasn't supposed to access.

This is part of XSA-328.

Reported-by: Jan Beulich <jbeulich@suse.com>
Signed-off-by: Roger Pau Monné <roger.pau@citrix.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>

x86/EPT: ept_set_middle_entry() related adjustments

ept_split_super_page() wants to further modify the newly allocated
table, so have ept_set_middle_entry() return the mapped pointer rather
than tearing it down and then getting re-established right again.

Similarly ept_next_level() wants to hand back a mapped pointer of
the next level page, so re-use the one established by
ept_set_middle_entry() in case that path was taken.

Pull the setting of suppress_ve ahead of insertion into the higher level
table, and don't have ept_split_super_page() set the field a 2nd time.

This is part of XSA-328.

Signed-off-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Roger Pau Monné <roger.pau@citrix.com>

x86/shadow: correct an inverted conditional in dirty VRAM tracking

This originally was "mfn_x(mfn) == INVALID_MFN". Make it like this
again, taking the opportunity to also drop the unnecessary nearby
braces.

This is XSA-319.

Fixes: 246a5a3377c2 ("xen: Use a typesafe to define INVALID_MFN")
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>

xen/common: event_channel: Don't ignore error in get_free_port()

Currently, get_free_port() is assuming that the port has been allocated
when evtchn_allocate_port() is not return -EBUSY.

However, the function may return an error when:
    - We exhausted all the event channels. This can happen if the limit
    configured by the administrator for the guest ('max_event_channels'
    in xl cfg) is higher than the ABI used by the guest. For instance,
    if the guest is using 2L, the limit should not be higher than 4095.
    - We cannot allocate memory (e.g Xen has not more memory).

Users of get_free_port() (such as EVTCHNOP_alloc_unbound) will validly
assuming the port was valid and will next call evtchn_from_port(). This
will result to a crash as the memory backing the event channel structure
is not present.

Fixes: 368ae9a05fe ("xen/pvshim: forward evtchn ops between L0 Xen and L2 DomU")
Signed-off-by: Julien Grall <jgrall@amazon.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>

x86emul: fix FXRSTOR test for most AMD CPUs

AMD CPUs that we classify as X86_BUG_FPU_PTRS don't touch the selector/
offset portion of the save image during FXSAVE unless an unmasked
exception is pending. Hence the selector zapping done between the
initial FXSAVE and the emulated FXRSTOR needs to be mirrored onto the
second FXSAVE, output of which gets fed into memcmp() to compare with
the input image.

Reported-by: Andrew Cooper <andrew.cooper3@citrix.com>
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Acked-by: Andrew Cooper <andrew.cooper3@citrix.com>
Tested-by: Andrew Cooper <andrew.cooper3@citrix.com>
Release-acked-by: Paul Durrant <paul@xen.org>